home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17005 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.2 KB  |  70 lines
  1. Newsgroups: comp.object,comp.lang.c++,comp.realtime,comp.dcom.telecom.tech,comp.arch.embedded
  2. Path: vtnt02.vantek.net!not-for-mail
  3. From: Sid Johnson <sjohnson@mail.vantek.net>
  4. Subject: Re: Can OO be successful in real-time embedded systems?
  5. Message-ID: <316F437B.40A0@mail.vantek.net>
  6. Date: Fri, 12 Apr 1996 23:02:35 -0700
  7. X-Mailer: Mozilla 2.0 (Win16; I)
  8. MIME-Version: 1.0
  9. References: <316BF0C5.1FE1@condat.de>
  10. Content-Type: text/plain; charset=iso-8859-1
  11. Content-Transfer-Encoding: 8bit
  12.  
  13. Henning Rietz wrote:
  14. > 
  15.  
  16. > 
  17. >         - "OO systems are too slow"
  18. >         - "OO systems eat up too much memory"
  19. > 
  20. > I believe, that this is not necessarily true but heavily related to
  21. > experience. Now I┤m asking you:
  22. > 
  23. >           How far "down" does the application of OO really go?
  24. >           How far will it go in the future?
  25. >           Who develops commercial(!) embedded real-time systems
  26. >               using OO methods and languages?
  27. >           Will OO ever be of major importance in that area?
  28. > 
  29. > 
  30. > 
  31. >The trick is to remember that C++ is just doing what you would like to do in C, but 
  32. doing it with better looking source code.  It provides modularity and extensibility without
  33. cluttering source code with pointers and it avoids global data without the call overhead of "get"
  34. functions (inline fns).  These are great maintainability advantages.
  35.  
  36. As for being a resource hog, that is a matter of self-discipline.  If you avoid exceptions
  37. and templates, are reasonable with inheritance, and hit a happy medium on what you call an 
  38. object, there is very little overhead.  In addition, for "single-instance" objects, you can make 
  39. the data and fns static and avoid the "this" pointer.  Even with virtual fns, if the objects are
  40. named at compile time instead of run-time, the virtual table is avoided altogether.
  41.  
  42. We are currently reengineering two existing products (similar but different) into one product 
  43. line using C++.  These products are characterized by several choices of optional peripherals, and 
  44. very complex interactions of internal features.  We have found C++ to be just the tool for 
  45. creating an architecture which simplifies the view of this software and gives the flexibility to 
  46. mix and match peripherals.
  47.  
  48. As for tools, there seems to be nothing below 32-bit except in the x86 family.  This is because 
  49. the Microsoft and Borland compilers support it.  Several other vendors provide linkers, locaters, 
  50. and debuggers to support these compilers.  With this approach, you can go as low as the x86 
  51. family goes.  As for OOA/D, the Rose tool supports these compilers.
  52.  
  53. I think the industry is really missing an opportunity to turn out much better software without 
  54. serious performance degradation -- even in the 8/16-bit market. :-)
  55.  
  56.  
  57. -- 
  58. __________________________________________________________________
  59. Sid        sjohnson@vantek.net
  60.  
  61. Come visit @ the Philosopher's Corner - http://www.vantek.net/pages/sjohnson/
  62.  
  63. In thinking, keep to the simple.  In conflict, be fair and generous.
  64. In governing, don't try to control.  In work do what you enjoy.
  65. In family life, be completely present.  
  66.                                                 Lao-Tzu
  67. ___________________________________________________________________
  68.  
  69.  
  70.